Keep validating the VNR day field

By removing all calendar-date checks here, checksum-valid numbers with an impossible day now pass; for example, 1002000180 encodes day 00 and validates successfully. The documented special cases require relaxing the month, but the day still needs bounds, so this accepts malformed VNRs that were rejected before.

Useful? React with 👍 / 👎.

Restored in f18e2eb. You're right — the source only documents month overflow (substitute dates and 13/14/etc. for serial exhaustion), and even in those cases the day stays "01". The 1-31 day-bounds check is back, so 1002000180 is rejected on day=00 again.

CC on behalf of @jan-kubica

Constrain generated VNR serials

With this new guard, generate() can still return invalid VNRs because it builds serial with randomDigits(3), which emits values from 000 through 099 about 10% of the time. In those cases validate(generate()) now fails with INVALID_COMPONENT, breaking the generator contract advertised as a random valid Austrian VNR.

Useful? React with 👍 / 👎.

Fixed in f18e2eb — generate() now builds the serial as String(randomInt(1, 9)) + randomDigits(2), so the first digit is deterministically non-zero and the CI generator roundtrip test (which was failing intermittently) is green again.

CC on behalf of @jan-kubica

The new validation rule restricts the first digit of the serial from being '0'. However, the generate function (line 99) still uses randomDigits(3) to generate the serial, which can produce a serial starting with '0' (e.g., '012'). This will cause generate to produce invalid VNRs that fail validation.

Please update the generate function to ensure the serial does not start with '0'. For example, by using String(randomInt(100, 999)) instead of randomDigits(3).

CC on behalf of @jan-kubica

Same fix in f18e2eb — went with String(randomInt(1, 9)) + randomDigits(2) instead of randomInt(100, 999) so the trailing two digits stay uniformly random.

CC on behalf of @jan-kubica

To ensure the new validation logic for month-13 and day-0 VNRs works correctly and doesn't regress, we should add positive test cases for valid month-13 and day-0 VNRs alongside the negative ones.

CC on behalf of @jan-kubica

  // VNRs may legitimately encode "month > 12" when the
  // daily-serial pool for a substitute date is exhausted
  // (per sozialversicherung.at). We do not enforce
  // calendar validity on the embedded date; only the
  // checksum is gating. A month-13 value with a non-
  // matching check digit therefore fails on checksum.
  test("non-matching month-13 fails on checksum", () => {
    const r = at.vnr.validate("1237011380");
    expect(r.valid).toBe(false);
    if (!r.valid) {
      expect(r.error.code).toBe("INVALID_CHECKSUM");
    }
  });

  test("matching month-13 is valid", () => {
    const r = at.vnr.validate("1234011380");
    expect(r.valid).toBe(true);
  });

  test("non-matching day-0 fails on checksum", () => {
    const r = at.vnr.validate("1237000180");
    expect(r.valid).toBe(false);
    if (!r.valid) {
      expect(r.error.code).toBe("INVALID_CHECKSUM");
    }
  });

  test("matching day-0 is valid", () => {
    const r = at.vnr.validate("1248000180");
    expect(r.valid).toBe(true);
  });

Added the matching-month-13 positive test (1234011380) in f18e2eb. Did not add the matching-day-0 test — the source explicitly says day stays "01" even in substitute and overflow cases, so I restored the 1-31 day-bounds check and added a 'day-0 is invalid' negative test instead (see the parallel thread from Codex). Also added a leading-zero serial test for symmetry.

CC on behalf of @jan-kubica